@Raimo33 As per @cdecker's suggestion here, we should modify the Dockerfile to run as a non-root user for improved security. Since we're already refactoring the Dockerfile, could we incorporate this change as well?

I'm removing the manual handling of tini in favor of a user controlled approach, more docker native and friendly.

ENTRYPOINT  [ "/usr/bin/tini", "-g", "--", "./entrypoint.sh" ]

becomes:

ENTRYPOINT  ["/entrypoint.sh"]

and the user is free to run the container with tini by using the official --init flag as follows:

docker run --init ...

The Dockerfile now should also support building the image from any host architecture as well. It previously only suppported amd64 to any. now it should be any to any, but I've no way of testing it

make install currently calls git describe to know the version of the program. This means that the .git/ folder needs to be copied into the Dockerfile for it to work. But copying the .git/ folder almost always invalidates the cache of the COPY . . command.

I'd like to explore ways to not include the .git/ folder (aka placing it in the .dockerignore). Maybe we can add an option to the Makefile that doesn't call git describe

Nice changes, and with the switch to uv things may get even a bit simpler still. Undraft once ready, and we'll review again and merge asap 👍

i dont want to undraft until these issues are addressed:

• arm 32 bit compilation fails
• manpages install takes 45 minutes
• COPY . . invalidates all following cache
• user creation
• clarity on [WIP] Refactor Dockerfile #8429 (comment)

When compiling for armv7 I'm getting this unaligned access error:

#49 7.927 checking for unaligned access to int... ccan/tools/configurator/configurator: Test for HAVE_UNALIGNED_ACCESS did not compile:
#49 7.959 configuratortest.c: In function 'main':
#49 7.959 configuratortest.c:8:22: error: array subscript 'int[0]' is partly outside array bounds of 'char[4]' [-Werror=array-bounds]
#49 7.959     8 |         return *x == *y;
#49 7.959       |                      ^~
#49 7.959 configuratortest.c:5:11: note: at offset 1 into object 'pad' of size 4
#49 7.959     5 |      char pad[sizeof(int *) * 1];
#49 7.959       |           ^~~
#49 7.959 cc1: all warnings being treated as errors
#49 7.960 
#49 ERROR: process "/bin/bash -euo pipefail -c ./configure --prefix=/tmp/lightning_install --enable-static --disable-compat --disable-valgrind" did not complete successfully: exit code: 3

This is because armv7 does not guarantee unaligned access support, so the compilation should rightfully fail. Now i wonder, are we sure that this repo is meant for armv7 as well? should we remove armv7 support completely? as far as I know it is only useful for raspberry pi 1 and 2. Raspberry PI's 3,4,5 have armv8 64bit.

I think someone should check if this compilation still works: (https://github.com/ElementsProject/lightning/blob/master/doc/getting-started/getting-started/installation.md#to-cross-compile-for-raspberry-pi)

@cdecker Adding a non-root USER directly inside the Dockerfile is not a reliable option when using mounted volumes. The reason is that file permissions on mounted volumes are determined by the UID and GID of the host system, not the container. Hardcoding a UID, for example USER 1000:1000, might work in some environments, but it is not guaranteed to match the host system’s user. On many systems, the first regular user is UID 1000, but this is not universal, and in environments like CI/CD runners, containers, or systems with different user configurations, the UID/GID may differ.

Hardcoding the UID inside the Dockerfile creates a fragile assumption and can easily lead to permission issues. Some repos such as mempool do just that, but I don't deem it robust.

I have fought with docker user permissions for years, and when there are volumes involved, unless using docker-compose, the best thing is running as root. Other ways are hacky workarounds that involve setting UID and GID specifically. docker-compose can abstract away these hacks but it's not our case